目錄

管理篇

1. 為何需要FID？
2. 如何開始FID
3. FID 的人物角色 (上)
4. FID 的人物角色 (下)
5. FID 的關鍵時刻
6. 變幻莫測的需求
7. FID之下一步要做什麼？

技術篇

1. 專案的技術組成
2. 技術儲備
3. 技術儲備之技術目的：開箱即用
4. 一眼看穿的程式
5. 技術儲備之人才：魚塘效益
6. 階段開發
7. 抽象化

執行篇

1. 回饋機制
2. 攻防機制
3. 確認機制
4. 導入機制
5. 衡量機制
6. 技術積累

設計篇

1. 設計語言
2. 最小化設計
3. 流程設計
4. 行為設計
5. 知識設計
6. 品質設計
7. 資料設計

心得

1. 超前部署和這次文章整理心得
2. FID 組織管理

FID Overview

Future-Ready Interface Development，以下簡稱 FID。

FID 旨在確保軟體的前端工程在面對未來的挑戰和變化時仍然保持高度適應性和性能，
從而為用戶提供優質的體驗並促進軟體的長期成功。

這個指的前端工程涵蓋面向用戶的各種終端。

• 手機
• 平板
• 桌機
• 電視
• 汽車顯示
• 網頁

背景

設計師與前端

在 CSS 發布後 26+年，CSS 已經成為網頁設計的基礎，但是 CSS 的設計並不是為了網頁設計，而是為了文件設計。CSS 的設計理念是，
將文件的樣式與文件的內容分離，讓文件的內容與樣式可以獨立編輯，並且可以重複使用。

而我們也在漫長的發展過程中，漸漸分離出專業的 UI 和 UX 領域，還有在台灣比較少人提及的 UX 工程師和 UX 分析師等等，這些都是為了讓網頁設計更專業，更有效率。

在業界的前端和設計師都知道，前端和設計的溝通，一直都存在共識問題，尤其是在設計稿的溝通上，設計師總是會覺得前端沒有實現設計稿，而前端總是會覺得設計師沒有考慮到前端的實現問題。

前端和後端系統

面向用戶的一方，我們統稱前端，更多人會誤以為前端僅限於 UI，而這種觀念放在 20 年前，可能是正確的，基於當時的技術上還有很多限制，但是在現在，這種觀念已經不合時宜。

為什麼呢？因為我們能透過瀏覽器做的事情太多了，我們可以製作複雜的遊戲，製作複雜的應用程式，甚至可以製作複雜的編輯器，這些都是在 20 年前，我們無法想像的。

Javascript 的發展，讓前端的能力越來越強大，而且 Javascript 的發展速度也越來越快，這也是為什麼前端工程師的需求越來越高的原因。

功能轉移到前端

當我們需要在前端實作複雜且龐大的功能時，會需要詳細的規劃，良好的設計原則，以及有序的工程實作，這些都是為了讓前端能夠更有效率的開發，並且能夠更容易的維護。

業務需求和快速開發

當我們處於快速回應市場需求的時候，我們需要快速的開發的方法，並且需要確保開發的品質。這時候我們會處於兩難。

因為快速的東西，往往品質都不會太好，而品質好的東西，往往都不會太快，這是一個經典軟體開發問題，也是一直存在的問題。

但是如何我們把自己想像成一個快餐店，我們可以快速的提供食物，而且品質也不錯，這是怎麼做到的呢？

於是我們開始思考，如何將軟體開發的流程，變成快餐店的流程，這樣的流程，就是 FID。

目標

FID 的目的是為了在組織、多專案並併發、多人維護的情況下，利用有限的資源建立一個專屬該組織的前端工程系統，並且能夠快速的開發出產品，而且產品的品質也能夠有保證。

設計原則

這裡指的設計不是指「外觀」如何，而是他是如何運作的，這裡的設計是指「設計模式」，而不是「設計風格」，而 FID 的設計原則有以下五點：

• 抽象原則 Abstraction of Design: FID 將設計視為可抽象和通用的元素。它強調設計的結構和元素應該被抽象化，以便能夠在不同情境中重複使用，從而提高重用性和效率。這促進了前端介面的一致性和可維護性。

• 程式基礎 Implementation is the Foundation: 推動專案的基礎是基於工程實作而建立，工程師在設計中扮演著核心角色之一。

• 資料驅動 Data-Driven Interface: 畫面以資料導向作為基礎，設計應該根據資料來驅動介面的呈現和表現方式。

• 設計延伸 Design-Driven Implementation: 實作應該根據設計來驅動實作的方式，實作應該是設計的延伸，如我們熟悉的 Design system 和 Design token.

• 依賴管理 Dependency Management: 將功能和需求按照其特性分類，並且將其分離，以便能夠更好地管理和維護。